IP Multimedia Subsystem (IMS) is a technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and to control calls or sessions between user entities or between a user entity or a client and a server. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. The 3GPP architecture defines different types of Call Session Control Functions (CSCFs), providing services to different user entities in an IMS.
There are a number of situations where an IMS client A may want to maintain updated information about another IMS client B, which have given client A access permission to do so. The Presences Service based on the IETF SIMPLE (SIP Instant Messaging and Presence Leveraging Extensions) technology is a particular application built on top of the SIP event notification framework. This type of service allows a user to be informed about the reachability, availability, and willingness of communication of another user. The presence service may be used to indicate whether different users are online or not and whether online users are idle or busy. The presence service may also give details of communication means and the respective capabilities of each communication means. A person who is providing presence information is typically called a presences entity, or presentity. A given presentity may have one or more entities operating as clients, typically also referred to as Presence User Agents (PUAs), which can supply updated presence information, i.e. a set of attributes that characterize the properties of the presentity, such as e.g. status, capabilities and/or communication address to a server, providing the presence service to subscribing users.
FIG. 1 schematically shows an exemplified scenario of a SIP presence architecture adapted to provide a presence service according to the prior art. In an IMS network 100, three clients 101-103, which may be any of e.g. an IMS terminal, a laptop, and/or a desktop computer, each have a piece of information about a presentity 104 stored locally. Different clients may hold different or identical information about the presentity 104. An IMS terminal may e.g. hold information about the registration status of the presentity 104, while a laptop may hold information as to if the presentity 104 is logged on or not. In addition, a client may hold richer presence information, such as e.g. whether the presentity is available for videoconferences and/or wants to receive a voice call at present. All presentity clients 101-103 send their respective pieces of information to a presences server 105, which gathers all information and obtains a complete picture of the presentity's 104 presence. FIG. 1 also shows two users 106,107, typically referred to as watchers, each equipped with a respective entity 108, 109, wherein each entity is operating as a respective watcher client, via which the respective user 106,107 may subscribe to presence information of a specific presentity or a number of presentities, specified in a list, i.e. a presentities presence list. The presence server 105 notifies all the subscribing watchers when a change has occurred in the respective presentity's presence information, i.e. when a presentity has delivered new presence information to the presence server 105 via a SIP PUBLISH request, by delivering the published information to the respective one or more watchers in a SIP NOTIFY request.
In current SIMPLE based solutions it is necessary for the presence server to send a new notification, comprising all data or parts of the data, i.e. partial notify, whenever a change occurs in the presence data. Such a notification must be sent no matter if the presence data has already been delivered to a respective watcher in a previous notification or not.
Since many of the notifications sent from the presence server to a watcher are just toggling of one data, such as “open” or “closed” for a service, a lot of data which has already been delivered between the two entities is sent over the air-interface. Even in the case of partial notifications, the size is not without significance.
In addition, repeated transmissions of identical data content requires more complicated functionality, rendering a costly processing, both at the server, creating a notification, and at the watcher, having to process each received notification and to create a final result on the basis of the processed content.